프로젝트 초기의 개발 방법

개요

• 크고 복잡한 프로젝트 진행시 초기에 작업 단위를 나누기 쉽지 않음
• 코드 아키텍트가 인터페이스를 모두 설계한 뒤 이슈를 나눠 진행하거나 할 수 있지만,
• 명확한 방향을 잡기 어려운 경우엔 어떻게 진행할지 고민

목표

• 코드 충돌 최소화
• 빠른 코드 반영 (하루 이상 넘기지 않는다)
• 팀원간 작업 공유 프로젝트 이해도 증가

빠른 페이스 개발 방법

방안1

매일 회의 후 같은 시각 같은 베이스에서 작업을 시작하여 충돌을 최소화한다.

1. dev->working 작업 브랜치 생성(초기)
2. 각자 이슈 생성, working -> feature 브랜치 생성, 어떤 작업 진행할건지 공유.
3. PR생성, 채널에 링크와함께 알린다(자동화, 혹은 참여를 유도하기 위해 직접 멘션).
4. 공통 작업시간에 리뷰 및 라이브 몹 프로그래밍.
5. 회의 끝나면 무조건 working 브랜치로 병합
6. 2~5 반복 후 특정 목표 달성 후 working -> dev로 병합.

방안2

병합 빈도를 빠르게 하여 충돌을 최소화한다.

1. 각자 이슈 생성, dev-> feature 브랜치 생성, 어떤 작업 진행할건지 공유.
2. PR생성, 채널에 링크와함께 알린다(자동화, 혹은 참여를 유도하기 위해 직접 멘션).
3. 일정 시간 열어두고(예: 2시간) 상시 리뷰 진행
4. 시간이 지나면 바로 병합. 병합을 알린다.
5. 공통 작업시간에 병합한 코드, 작업 중인 코드(열린 PR이 있는 경우) 공유하며 라이브 몹 프로그래밍 진행

이후

• 어느정도 개발이 진행되면 이슈 리스트를 만들고 각자 이슈를 부여하여 진행하도록 한다.
• 매일 같이 PR하는 것은 유지.
• 같이 프로젝트를 파악하며 그 코드들이 계속해서 반영되도록 한다.

중간 회고 2022-11

• OOP를 활용하는 구조는 관리가 어렵다.
  • 팀원들이 어떤 개발을 하는지 파악하라
    • 절차지향 (단순)
      • 구조를 파악하지 않고 짜다보니 자기가 짠 코드가 계속 사이드이펙트가남
    • 구조 지향 (오버 엔지니어링)
    • 조심스럽게 접근하는 사람
• 함수형 패러다임을 쓰는 이유
  • 코드 중복을 어느정도 허용해도된다.
  • 함수 단위로 리뷰해서 코드 관리가 좀 더 용이해질 수 있다
    • 숲을 볼 수 있는 사람은 매우 한정적이다.
  • 단점은 함수가 뭐가 있는지 파악해야함 (뭐 구조도 똑같지...)